The present disclosure generally relates to cloud IT services delivery. The disclosed embodiments relate more specifically to a system, apparatus, method, and computer program product for providing multi-redundant switchable process pooling cloud IT service delivery.
The information technology (IT) industry is migrating toward automated solutions that are fairly complex and frequently involve the point-to-point integration of multiple products and services (e.g., provisioning engines, functional products such as security, external cloud services, etc.) to deliver a complete solution, such as a private, hybrid, or public cloud, that addresses a particular market or business need, such as self-service delivery of automated Cloud IT Services. Frequently, and as a rapidly increasing broad, practice in the industry, such point-to-point integrations are accomplished with light-weight run-book automation (RBA) processes and connectors. Such point-to-point integrations are rapidly gaining acceptance in the industry as a whole. The integration of IT services via RBA-type orchestration technologies, however, presents several challenges.
In purpose built solutions for orchestrating and automating cloud IT services across a breadth of capabilities and in all multi-product solutions, the integrity of the products and/or services being delivered is dependent on the integrity of the underlying sets of processes, content, and integrations. Many of those services typically are mission critical and/or chargeable services. And the integrity and supportability of the corresponding processes or process sets must be maintained, managed, and preserved in a production environment without compromising the flexibility of process-based, light-weight integrations and automation so that those processes or process sets can be used in multiple environments.
Each customer environment is unique and has needs for potential variations to processes to match each customer's business needs. For example, the process or number of approvals required for the fulfillment of a service request for a first service provider may be different from that of a second service provider, which may be different than the number of approvals required for an enterprise, even though the basic cloud IT service offered by all three generally is the same. That challenge typically is solved by modifying the corresponding process from the process or process set that is delivering the cloud IT service as required to suit a particular customer environment or need. That approach, however, is tedious, involves manual intervention, and is prone to errors.
Such errors may break the integrity of the process or process set, which may require potential downtime and/or a thorough re-testing of all other processes in the process or process set to ensure the integrity of the cloud IT service or the multi-product solution being delivered. Moreover, the result of modifying the process or process set is to create one-off implementations, which are difficult to keep track of, manage, and sustain (e.g., fault isolation, updates, diagnosis, etc.). And in an industry that has proliferated a large number of cloud IT services and multi-product solutions that each have a large number of different variations of orchestration process driven integrations that make those services and solutions possible, keeping track of, managing, and sustaining those processes or process sets on an ongoing basis is even more challenging.
Among the specific challenges associated RBA-type orchestration technologies is organizing content related to a cloud IT service into a distributable package. In the context of a cloud IT service delivery solution, the content, processes, connectors, etc. distributed in a particular package are essentially related to and representative of a service. Packaged content, while relatively easy to distribute and configure, loses its context once un-packaged. Accordingly, after content is installed, it is indistinguishable from other processes or content that exists in the environment. In other words, the distributed package is assimilated when it is installed and, therefore, is difficult to manage after that.
Another challenge associated with RBA-type orchestration technologies is that packaged content is easily and necessarily modifiable in the field. Because changes to the content represent changes to the service, managing such changes becomes a crucial and challenging requirement for maintaining the context of the cloud IT service. But even when packaged content correctly represents a cloud IT service, it provides no context for the operations, management, or lifecycle of the cloud IT service it represents (e.g., activation/de-activation, entitlements, metering, changes, content updates, etc.). And without the proper context, the integrity of the cloud IT service being delivered, and even the integrity of the entire solution, will depend on the integrity and manageability of the underlying sets of processes and integrations packaged that are packaged for distribution.
In addition, the entitlement context of a cloud IT service must be maintained. Although packaged content may be access controlled, it has no service context of entitlements. Moreover, packaged content cannot address dependencies, field updateability, or changes related to the support of content packages. And a packaged content set does not maintain state, while a cloud IT service must maintain state in the context of a particular solution (e.g., “is this service active/in-active”). It is those features, among others, that make keeping track of, managing, and sustaining processes and process sets so challenging.